Great first PR! I noticed a few things, please rectify them.

1. The kernel-build.log file is not attached.
2. The kselftest-after.log file is not uploaded. Doesn't link to anything.
3. There are two kselftest-before.log file links. The first link is to a PR and not to a file.
4. The build log shows that the kABI check passed but you forgot to tick the check box for the kABI check (this is at the very beginning of the PR text).

You can edit the PR and,

1. Upload/attach the kernel-build.log file.
2. Remove the last few lines for kselftest-*.log files and re-upload them.
3. Add an x between the [ ] brackets in the kABI Check Passed, where Valid (Pre 9.4 RT does not have kABI stability) list item.

Great first PR! I noticed a few things, please rectify them.

1. The kernel-build.log file is not attached.
2. The kselftest-after.log file is not uploaded. Doesn't link to anything.
3. There are two kselftest-before.log file links. The first link is to a PR and not to a file.
4. The build log shows that the kABI check passed but you forgot to tick the check box for the kABI check (this is at the very beginning of the PR text).

You can edit the PR and,

1. Upload/attach the kernel-build.log file.
2. Remove the last few lines for kselftest-*.log files and re-upload them.
3. Add an x between the [ ] brackets in the kABI Check Passed, where Valid (Pre 9.4 RT does not have kABI stability) list item.

1. kernel-build.log file is already there - mptcp: cope racing subflow creation in mptcp_rcv_space_adjust #175

2. I've updated kselftest-after.log` file. There was a syntax mistake.

I looked at this and got a merge conflict on the fuzz above the conflicted change.

 tcp_sk(ssk)->window_clamp = window_clamp;
vs
 WRITE_ONCE(tcp_sk(ssk)->window_clamp, window_clamp);

Because the ssk data is used in both lines I investigated why they added the annotations:
torvalds/linux@f410cbe

Since it looks like they're exclusively referring to window_clamp and data race I didn't investigate to see if we should bring in this commit for annotation as it would require us to validate that all the assurances that that ssk->window_clam assertions are true that it can be read locklessly, as the sk_rcvbuf has these annotations without window_clamp.

I'm not going to block this for an update since we don't have a codified method of dealing with conflicts in surrounding code but usually if the code in conflict shares the same variables / symbols we might want to mention it, even if its not in the commit message and what we learned.

Maybe we add this to the PR as like an due diligence check, I could open a discussion on an Issue for public committers to
weigh in?

I'm not going to block this for an update since we don't have a codified method of dealing with conflicts in surrounding code but usually if the code in conflict shares the same variables / symbols we might want to mention it, even if its not in the commit message and what we learned.

Maybe we add this to the PR as like an due diligence check, I could open a discussion on an Issue for public committers to weigh in?

Mentioning merge conflicts for surrounding code in the PR seems like a good idea. I've typically not mentioned them in the 'upstream-diff' section of the commit message with the justification that they technically aren't a difference from the code that was changed in the upstream commit. However I do look at those surrounding conflicts and make a determination about whether they are relevant or not. Not mentioning them at all might prevent the case where a reviewer makes a different determination as to their relevance than I did.

In this particular case I also noticed the surrounding difference and also determined that I didn't think they were relevant to the changeset under review.

TLDR; For backported code, let's mention merge conflicts in the code surrounding the code change under review at least in the PR, or even in an 'upstream-diff' commit log section if you think it might be useful to a future commit log reader.

Merge away @jainanmol84

I looked at this and got a merge conflict on the fuzz above the conflicted change.

 tcp_sk(ssk)->window_clamp = window_clamp;
vs
 WRITE_ONCE(tcp_sk(ssk)->window_clamp, window_clamp);

FWIW, the upstream stable backport to 6.1.119 mentioned in https://lore.kernel.org/linux-cve-announce/2024120252-CVE-2024-53122-f35c@gregkh/T/#u also has this without the WRITE_ONCE, so at least we won't be alone with this combination (of no WRITE_ONCE addition and this fix):

$ git show 24995851d58c --pretty=fuller
commit 24995851d58c4a205ad0ffa7b2f21e479a9c8527
Author:     Paolo Abeni <[email protected]>
AuthorDate: Tue Nov 19 09:35:49 2024 +0100
Commit:     Greg Kroah-Hartman <[email protected]>
CommitDate: Fri Nov 22 15:37:33 2024 +0100

    mptcp: cope racing subflow creation in mptcp_rcv_space_adjust
    
    commit ce7356ae35943cc6494cc692e62d51a734062b7d upstream.
    
    Additional active subflows - i.e. created by the in kernel path
    manager - are included into the subflow list before starting the
    3whs.
    
    A racing recvmsg() spooling data received on an already established
    subflow would unconditionally call tcp_cleanup_rbuf() on all the
    current subflows, potentially hitting a divide by zero error on
    the newly created ones.
    
    Explicitly check that the subflow is in a suitable state before
    invoking tcp_cleanup_rbuf().
    
    Fixes: c76c6956566f ("mptcp: call tcp_cleanup_rbuf on subflows")
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/02374660836e1b52afc91966b7535c8c5f7bafb0.1731060874.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    [ Conflicts in protocol.c, because commit f410cbea9f3d ("tcp: annotate
      data-races around tp->window_clamp") has not been backported to this
      version. The conflict is easy to resolve, because only the context is
      different, but not the line to modify. ]
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 78ac5c538e13..1acd4e37a0ea 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -2057,7 +2057,8 @@ static void mptcp_rcv_space_adjust(struct mptcp_sock *msk, int copied)
                                slow = lock_sock_fast(ssk);
                                WRITE_ONCE(ssk->sk_rcvbuf, rcvbuf);
                                tcp_sk(ssk)->window_clamp = window_clamp;
-                               tcp_cleanup_rbuf(ssk, 1);
+                               if (tcp_can_send_ack(ssk))
+                                       tcp_cleanup_rbuf(ssk, 1);
                                unlock_sock_fast(ssk, slow);
                        }
                }

What's important is to not try backporting this fix to kernels that don't have the commit listed in Fixes. According to RH, they fixed this even for EL8, so perhaps they had backported the buggy commit to there - but this doesn't tell us when they did that. We may have 8.x LTS branches that don't have that, so need to be careful to check first.

TLDR; For backported code, let's mention merge conflicts in the code surrounding the code change under review at least in the PR, or even in an 'upstream-diff' commit log section if you think it might be useful to a future commit log reader.

Here's how the same conflict is mentioned in the upstream stable commit I quoted above:

    [ Conflicts in protocol.c, because commit f410cbea9f3d ("tcp: annotate
      data-races around tp->window_clamp") has not been backported to this
      version. The conflict is easy to resolve, because only the context is
      different, but not the line to modify. ]

Re: Merge conflict

This PR exists as the result of me helping Amol get familiar with the Kernel CVE process by making her fix one CVE and assisting in that. I focused on the process of it and not much on the CVE fix itself because I believe that Anmol can/should handle that, given her experience with userspace CVEs.

Given that the issue was introduced with v5.10, when we were presented with a merge conflict, I suggested that we pull in the patch from v5.15--the closest longterm tree. The commit's message is generated by our cherry pick script but the actual diff is from the patch merged in the v5.15 tree: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/mptcp/protocol.c?h=v5.15.179&id=0a9a182ea5c7bb0374e527130fd85024ace7279b

+1 on mentioning if there is a merge conflict and the engineer's solution for it.

As long as we always use the Upstream Commit SHA but you can see that RedHat made changes from the 5.10. so a different line would have been in conflict but ultimately still in contextual information.

I have updates I need to do to the WIKI anyways to remove RT stuff so maybe I'll include that if everyone generally agrees.